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FIELD OF THE INVENTION 

The present invention relates generally to the field of e-commerce 
and, more specifically, to the harvesting of feedback information, opinions 
5 and comments regarding multiple items from users of a network-based 
transaction facility such as, for example, an Internet-based auction facility. 



BACKGROUND OF THE INVENTION 

In addition to access convenience, one of the advantages offered by 
J1 10 network-based transaction facilities (e.g., business-to-business, business-to- 

3 consumer and consumer-to-consumer Internet marketplaces and retailers) 

and on-line communities is that participants within such facilities or 
communities may provide feedback to the facility, to other users of the 
facility and to members of an on-line community regarding any number of 
15 topics. 

For example, an Internet-based retailer may provide a feedback 
mechanism whereby customers may provide feedback, in the form of 
comments or opinions, regarding goods or services offered for sale by the 
retailer. An Internet-based bookstore may, for example, provide a feedback 
20 mechanism whereby comments or opinions regarding particular books may 
be submitted via a web site operated by the book retailer. Such comments 
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are then displayed within a web page, pertaining to the relevant book, 
generated by the Internet-based book retailer. Such comments and feedback 
are useful in assisting a purchaser with a buying decision. 

For users of a network-based transaction facility, such as an Internet- 
based auction facility, feedback regarding other users is particularly 
important for enhancing user trust of the transaction facility. Indeed, a 
history of positive feedback for a trader that routinely uses an Internet-based 
auction facility may be particularly valuable and useful in providing other 
traders with a degree of confidence regarding a specific trader. Accordingly, 
a positive feedback history may establish the credibility and trustworthiness 
of a particular trader within an on-line trading community. Similarly, a 
history of negative feedback may discourage other traders from transacting 
with a specific trader. 



SUMMARY OF THE INVENTION 

According to one aspect of the present invention, a method of 
displaying a user interface, to harvest feedback pertaining to transactions 
facilitated by a computerized transaction facility, displays transaction 
identification information for each of the plurality of transactions within a 
user interface displayed on a display device. A feedback input for each of 
the plurality of transactions is displayed within the user interface, as 
displayed on the display device. Each feedback input is displayed so as to 
indicate an association with respect to transaction identification information. 

Other features of the present invention will be apparent from the 
accompanying drawing and from the detailed description that follows. 



BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention is illustrated by way of example and not 
limitation in the figures of the accompanying drawings, in which like 
references indicate similar elements and in which: 

Figure 1 is a block diagram illustrating an exemplary network-based 
transaction facility in the form of an internet-based auction facility. 

Figure 2 is a database diagram illustrating an exemplary database for 
the transaction facility. 

Figure 3 is a diagrammatic representation of an exemplary 
transaction record table of the database illustrated in Figure 2. 

Figure 4 is a diagrammatic representation of an exemplary feedback 
table of the database illustrated in Figure 2. 

Figure 5 is a diagrammatic representation of an exemplary feedback 
details table of the database illustrated in Figure 2. 

Figure 6 illustrates an exemplary interface sequence, according to one 
embodiment, that may be implemented by the transaction facility for the 
purposes of harvesting feedback, comments, opinions or reviews. 



Figures 7A - 7B are flow charts illustrating an exemplary method of 
harvesting feedback, comments or reviews pertaining to transactions 
facilitated by a network-based transaction facility. 

Figure 8 illustrates an exemplary logon interface for accessing a 
feedback mechanism of the transaction facility. 

Figure 9 is a flow chart illustrating an exemplary method of 
displaying a user interface to harvest feedback, comments and opinions 
pertaining to multiple items. 

Figure 10 illustrates an exemplary "exceeds threshold" multiple 
feedback interface. 

Figure 11 illustrates an exemplary filtered multiple feedback 
interface, that may follow the "exceeds threshold" interface following 
filtering of transactions. 

Figure 12 illustrates an exemplary "does not exceed threshold" 
feedback interface. 

Figure 13 illustrates an exemplary "confirmation" interface. 



Figure 14 is an object diagram illustrating exemplary objects of the 
transaction facility that may be utilized to harvest multiple feedbacks, 
opinions or comments from users of a transaction facility. 

Figure 15 is a diagrammatic representation of a machine, in an 
exemplary form of a computer system, in which a set of instructions for 
causing the machine to perform any of the methodologies of the present 
invention may be executed. 
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DETAILED DESCRIPTION 

A method and system for harvesting feedback information, comments 
and opinions regarding multiple items from users of a network-based 
transaction facility are described. In the following description, for purposes 
5 of explanation, numerous specific details are set forth in order to provide a 
thorough understanding of the present invention. It will be evident, 
however, to one skilled in the art that the present invention may be practiced 
without these specific details. 

10 Terminology 

For the purposes of the present specification, the term "transaction" 
shall be taken to include any communications between two or more entities 
and shall be construed to include, but not be limited to, commercial 
transactions including sale and purchase transactions, auctions and the like. 

15 

Transaction Facility 
Figure 1 is block diagram illustrating an exemplary network-based 
transaction facility in the form of an Internet-based auction facility 10. While 
an exemplary embodiment of the present invention is described within the 
context of an auction facility, it will be appreciated by those skilled in the art 
20 that the invention will find application in many different types of computer- 
based, and network-based, commerce facilities. 

The auction facility 10 includes one or more of a number of types of 
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front-end servers, namely page servers 12 that deliver web pages (e.g., 
markup language documents), picture servers 14 that dynamically deliver 
images to be displayed within Web pages, listing servers 16, CGI servers 18 
that provide an intelligent interface to the back-end of facility 10, and search 
servers 20 that handle search requests to the facility 10. E-mail servers 21 
provide, inter alia, automated e-mail communications to users of the facility 
10. 

The back-end servers include a database engine server 22, a search 
index server 24 and a credit card database server 26, each of which 
maintains and facilitates access to a respective database. 

The Internet-based auction facility 10 may be accessed by a client 
program 30, such as a browser (e.g., the Internet Explorer distributed by 
Microsoft Corp. of Redmond, Washington) that executes on a client machine 
32 and accesses the facility 10 via a network such as, for example, the 
Internet 34. Other examples of networks that a client may utilize to access 
the auction facility 10 include a wide area network (WAN), a local area 
network (LAN), a wireless network (e.g., a cellular network), or the Plain 
Old Telephone Service (POTS) network. 

Database Structure 
Figure 2 is a database diagram illustrating an exemplary database 23, 
maintain by and accessed via the database engine server 22, which at least 
partially implements and supports the auction facility 10. The database 23 



may, in one embodiment, be implemented as a relational database, and 
includes a number of tables having entries, or records, that are linked by 
indices and keys. In an alternative embodiment, the database 23 may be 
implemented as collection of objects in an object-oriented database. 

Central to the database 23 is a user table 40, which contains a record 
for each user of the auction facility 10. A user may operate as a seller, buyer, 
or both, within the auction facility 10. The database 23 also includes item 
tables 42 that may be linked to the user table 40. Specifically, the tables 42 
include a seller items table 44 and a bidder items table 46. A user record in 
the user table 40 may be linked to multiple items that are being, or have 
been, auctioned via the facility 10. A link indicates whether the user is a 
seller or a bidder (or buyer) with respect to items for which records exist 
within the item tables 42. The database 23 also includes a note table 48 
populated with note records that may be linked to one or more item records 
within the item tables 42 and/ or to one or more user records within the user 
table 40. Each note record within the table 48 may include, inter alia, a 
comment, description, history or other information pertaining to an item 
being auction via the auction facility 10, or to a user of the auction facility 10. 

A number of other tables are also shown to be linked to the user table 
40, namely a user past aliases table 50, a feedback table 52, a feedback details 
table 53, a bids table 54, an accounts table 56, an account balances table 58 
and a transaction record table 60. 

Figure 3 is a diagrammatic representation of an exemplary 
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embodiment of the transaction record table 60 that is populated with 
records, or entries, for completed, or ended, transactions (e.g., auctions) that 
have been facilitated by the auction facility 10. The table 60 includes a 
transaction identifier column 62 that stores a unique transaction identifier 
for each entry, and an end date column 64 that stores a date value indicating, 
for example, a date on which a transaction was established. A bidder 
column 66 stores a user identifier for a bidder (or a purchaser), the user 
identifier comprising a pointer to further user information stored in the user 
table 40. Similarly, a seller column 68 stores, for each entry, a user identifier 
for a seller within the relevant transaction. An item number column 70 
stores, for each entry, an item number identifying the goods or service being 
transacted, and a title column 72 stores, for each entry, a descriptive title for 
the relevant transaction or for the item being transacted. 

It should be noted that, in one embodiment, an entry is only created 
in the transaction record table 60 for transactions that have been established, 
for example, by the conclusion of an auction process, or by some other offer 
and acceptance mechanism between the purchaser and the seller. 

Figure 4 is a diagrammatic representation of an exemplary 
embodiment of the feedback table 52. The feedback table 52 stores summary 
information regarding feedback for users of the auction facility 10. The table 
52 includes a user identifier column 74 that stores, for each entry, a user 
identifier providing a pointer to the user table 40. A total score column 76 
stores, for each user entry, a total number of feedback comments (e.g., 



-11- 



negative, positive and neutral), received for the relevant user. A total 
negative column 78 stores, for each user entry, the total number of negative 
feedback comments for the relevant user, and a total positive column 80 
similarly stores, for each user entry, the total number of positive feedback 
comments received for that user. A number of retractions column 82 stores, 
for each user entry, the number of threads that the relevant user has 
retracted from auctions. 

Figure 5 is a diagrammatic representation of one embodiment of the 
feedback details table 53, that is populated with entries reflecting the details 
of each feedback comment or opinion submitted by a user to the auction 
facility 10 regarding another user or item involved in a transaction. In one 
exemplary embodiment, users are only permitted to provide feedback 
pertaining to a transaction upon conclusion of that transaction. The 
feedback information may pertain to a further user that participated in the 
transaction, or to the object (e.g., goods or services) that was the subject of 
the transaction. In an alternative embodiment, for example, comments or 
opinions are provided regarding an item or service that is offered for sale or 
regarding an event. In these cases it will be appreciated that a transaction is 
necessarily required for feedback to be permitted. 

The feedback details table 53 includes an item number column 84 
including an item identifier that points to a record within the item tables 42. 
A comment column 86 stores, for each entry, the actual text of the feedback, 
comment, or opinion. A type column 88, in one embodiment, stores 
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indication as to whether the comment is positive, negative or neutral A 
date column 90 stores, for each entry, the date on which the feedback, 
comment or opinion was delivered. A response column 92 stores the text of 
a response submitted by a user (e.g., a user to which the original comment 
pertained) in response to the comment text stored in column 86. Similarly, a 
rebuttal column 94 stores the text of a rebuttal to such a response. 

A commentator column 96 stores the user identifier of the user that 
submitted the original comment, stored in column 86, for the entry. A 
commentee column 98 stores the user identifier of the user to which 
comment may have been directed. 

It will be appreciated that further dates and other descriptive 
information may also populate the feedback details table 53. 

Multiple Feedback Items 
In order to facilitate the convenient provision of feedback by users of 
the auction facility 10 pertaining to a transaction (e.g., an auction 
transaction) in which a user participated, the present invention proposes a 
method and system whereby a user may conveniently provide feedback 
pertaining to multiple transactions. By facilitating the harvesting of multiple 
feedbacks for a multiple transaction via a unified mechanism, the invention 
addresses the inconvenience of tracking down multiple auctions via other 
indirect channels or mechanisms that may be provided by web site. In one 
embodiment, the present invention facilitates the provision of multiple 
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feedbacks pertaining to respective multiple transactions via a single interface 
(e.g., a markup language page interface). While the present invention is 
discussed within the context of providing feeding regarding transactions 
within a user is participated, it will readily be appreciated that the present 
invention may be extended to providing multiple feedbacks, comments or 
opinions pertaining to respective multiple products, events or other entities. 
For example, a book reviewer, utilizing the teachings of the present 
invention, may conveniently provide comments, reviews or opinions 
pertaining to multiple books. 

Figure 6 shows an interface sequence 100, according to an exemplary 
embodiment of the present invention, that may be implemented by the 
auction facility 10 for the purposes of harvesting feedback (or comments, 
opinions or reviews) from users of the auction facility 10. The auction 
facility 10 may, in one embodiment, only permit a user to provide feedback 
pertaining to a transaction within which that user wants a participant and 
which has been established or completed. For example, a transaction may 
be established through the identification of the winner of an auction, which 
creates the implicit understanding that the established transaction, between 
the purchaser (i.e., the winning bidder) and the seller, will be completed by 
performance of the reciprocal obligations underlying the transaction. 

The sequence 100 of interfaces shown in Figure 6 will be described 
with reference to the flow chart shown in Figures 7 A and 7B. Exemplary 
representations of the various interfaces included with the sequence 100 are 
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shown in Figures 8 - 12. 

On the ending of an auction, and the identification of winning bidder, 
the auction facility 10, via the e-mail servers 21, issues an end-of-auction e- 
mail 102 to both the winning bidder and the seller advising both parties of 
5 the outcome of the auction, and providing respective contact details to allow 
the parties to contact each others. 

The interface sequence 100 commences with a logon interface 108 
through which a user of the facility 10 provides at least a user identifier and 
associated password. The logon interface 108 may be accessed, in one 

10 embodiment, via three mechanisms, namely an end-of-auction e-mail 102, a 
view item (auction ended) interface 104 or a feedback services interface 106, 
each of which comprises a markup language document (e.g., HTML 
document) including a hypertext link to an object (which will be described 
in further details below) that generates the logon interface 108 as well as 

15 further interfaces of the sequence 100. The end-of-auction e-mail 102, as 

noted above, is communicated by the e-mail servers 21 of the auction facility 
10 to both a winning bidder and a seller upon the end of the auction process, 
the e-mail 102 notifying respective parties about the end of the auction and 
also providing contact details. The view item (auction ended) interface 104 

20 is presented to a user, at conclusion of an auction, when seeking further 
information regarding the item that was the subject of the auction. For 
example, upon conclusion of an auction, a textual description of the subject 
of the auction may be hypertext linked to generate the interface 104. The 
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feedback services interface 106 may be accessed, for example, through a site 

navigation menu or toolbar that presents the option to a user of leaving 

feedback. The feedback services interface 106 is typically used to leave 

feedback where a user does not know the item number identifying an item 

5 or where a user wishes to view feedback concerning multiple auctions 

within which t user has been a participant within a predetermined period of 

time (e.g., the past 60 days). 

□ The interface 108, and subsequent interfaces 110 - 116, are generated 

'A 

Lfj by a collection of objects (or methods), exemplary embodiments of which are 

jjj 10 illustrated in Figure 14. Specifically, a logon interface 108 is generated by a 

m 

: g "LeaveFeedbackToMultipleUsersShow" object 118. The object 118 is also 

~ ' responsible for generating a "threshold exceeded" multiple feedback 

jrjj interface 110, a filtered multiple feedback interface 112, a "does not exceed 

1 ^ threshold" feedback interface 114 and a confirmation interface 116, as will be 

y 15 described in further detail below. To this end, the object 118 issues calls to a 

"LeaveFeedbackToMultipleUsers" object 120 that is responsible for actually 
recording feedback inputted via the interfaces 108 - 116 to the database 23, 
and specifically the feedback and feedback details tables 52 and 53. The 
object 118 also issues calls to a "GetSellerListForFeedback" object 122 that 
20 retrieves a list of sellers and items from the transaction record table 60, for a 
clearing user identified by a specific user identifier. The object 122 includes 
a "UserltemRecord" vector 126 that is used as a container for the retrieved 
user and item information, the contents of the vector 126 being released to 
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the object 118. 

The object 118 similarly issues a call to a "GetBidderListForFeedback" 
object 124 that retrieves a list of bidders and items from the transaction 
record table 60 of the database 23 where the bidders have both items from a 
5 specific user identified by an inputted user identifier. The object 124 
similarly uses the ,, UserItemRecord ,, vector to pass bidder and item 
information to the object 118. 
□ The interfaces 108 - 116 will now be described within the context of a 

Lfj method 128, according to one embodiment of the present invention, of 

10 harvesting feedbacks, comments or opinions regarding multiple items from 
users of a network-based transaction facility. The method 128 is illustrated 
by the flow chart indicated in Figure 7A and 7B. 

The method 128 commences with a logon confirmation operation at 
block 130 performed utilizing a user identifier and a password. Specifically, 
15 the logon interface 108, an exemplary embodiment of which is illustrated in 
Figure 8, provides a user identifier field 180 and password field 182 into 
which a user may enter a user identifier and password to enable the logon 
confirmation operation at block 130. The logon interface 108 illustrated in 
Figure 8 also includes a further target user identifier field 184, into which a 
20 commentator user (identified by the user ID entered into fields 180) can 
specify the user identifier of a further user to which the feedback, or 
comments, are applicable. An item number field 186 also allows a 
commentator user 186 to specify a specific item number (e.g., identifying an 
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auction) if the feedback that the commentator user wishes to leave is to be 
directed towards a specific item. Input into the fields 184 and 186 is 
optional, and may function as filter criteria so that only a limited number of 
information items are presented in a subsequent multiple feedback interface. 

Returning to Figure 7 A, at block 132, the object 118 issues calls to the 
"GetSellerListForFeedback" object 122 and the "GetBidderListForFeedback" 
object 124 to retrieve a list comprising multiple completed transactions for 
which the commentator user was either a successful bidder or seller. The 
objects 122 and 124 retrieve the relevant transaction information from the 
transaction record table 60 of the database 23, and only retrieve transaction 
records for which no feedback has been left and which were established 
within a predetermined time period (e.g., the past 60 days). To this end, the 
objects 122 and 124 may identify records within the transaction record table 
60 for which the feedback column 73 indicates that no feedback has been left, 
and transaction records for which date information included within the end 
date column 64 identifies the transaction has been established within the 
predetermined time period. 

In one embodiment, the predetermined time period may be a default 
value that is automatically specified. In an alternative embodiment, a "time 
frame 1 ' input field may be provided within the logon interface 108, utilizing 
which a commentator user may specify the predetermined time period. 

At decision box 134, the object 118 makes a determination as to 
whether more than a predetermined number (e.g., 25) transaction records 
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are retrieved from the transaction record table 60 at block 132. Following a 
positive determination at decision box 134, at block 136, the object 118 
retrieves a first template (e.g., an ISAPI page) that provides for pagination 
and includes a filter field, as will be described in further detail below. 
Following a negative determination at decision box 134, the object 118 
retrieves a second template (e.g., an ISAPI page) that, while facilitating 
pagination, does not provide a filter field. 

At block 138, the template retrieved at block 136 or 140 is populated 
by ISAPI code, utilizing the contents of the "UserltemRecord" vectors 126 
returned by the objects 122 and/or 124 to generate a feedback interface (e.g., 
the multiple feedback interface 110 or 114). 

At block 142, the feedback interface generated at block 138 (e.g., 
HTML code) is communicated, via the Internet 34, to the client program 30 
(e.g., a browser) for display. 

At decision box 144, a determination is made as to whether a filter 
criterion has been applied to the transaction records by a commentator user. 
If so, at block 146, the object 118 may issue fresh calls to the objects 122 and 
124 to retrieve a modified list of transaction and user information. In an 
alternative embodiment, the object 118 may simply discard objects (or 
vectors) previously returned by the objects 122 and 124 that do not meet the 
filter criteria. 

At block 148, feedback information, comments or opinions are 
received at the auction facility 10 from the client program 30 and specifically 
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from the relevant interface communicated at block 142. The feedback 
information may, in one embodiment, include a number of feedback items, 
each feedback item including date information specifying a date on which 
the feedback was provided, comment information providing the actual 
textual content of the feedback, type information indicating whether the 
feedback is positive, negative or neutral, user identifier information 
identifying both the commentator and the target (or commentee) users and 
any other pertinent information. In exemplary embodiments, which are 
further described below, the feedback interfaces may comprise markup 
language documents (e.g., HTML pages) that include radio buttons or check 
boxes that may be utilized to identify whether a feedback item is provided 
with respect to an underlying information item (e.g., an auction) and that 
may also be utilized to identify the type of feedback being provided (e.g., 
positive, negative or neutral). 

At block 150, the object 118 makes a call to the 
"LeaveFeedbackToMultipleUsers" object 120 to create multiple instances of 
the object 120, each object containing the details of each of the feedback 
items received at block 148. Accordingly, instances of the object 120 may be 
viewed as containers for each of the feedback items. 

Proceeding to Figure 7B, at decision box 190, a determination is made 
as to whether any of the feedback has been categorized via the commentator 
user as being of a negative or neutral type. If so, at block 192, the object 118 
generates the confirmation interface 116 (e.g., in the form of an HTML 
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document) that is communicated from the auction facility 10 to the client 
program 30. The confirmation interface 116 prompts the commentator user 
for confirmation regarding any negative or neutral comments. At decision 
box 194, a determination is made as to whether all negative or neutral 
5 feedback comments have been confirmed. If not, the unconfirmed feedback 
is deleted at block 196. Following a positive determination at decision box 
194, or following a negative determination at decision box 190, or following 
completion of block 196, the method proceeds to block 152, where the object 
Lq 118 issues an IS API call to an error_check function (not illustrated) that 

!Jj 10 comprises a kernel module, and that performs a number of checks with 

S| respect to each feedback item, embodied within an instance of the object 120. 

\J\ 

~ For example, the error_check function may determine whether the 

ni commentator, or target, user has been suspended from the auction facility 

[ 5 r 10, whether feedback has already been submitted for the respective 

^ 15 transaction, whether the commentator user has been a member of the 

'erf 

auction facility 10 for less than predetermined time (e.g., five days) or 
whether a reserve price has been met for the relevant item (or transaction) to 
which the feedback comment pertains. If any of the conditions embodied 
within the error_check function are not met, the relevant feedback comment 
20 is deleted, for example by deleting the instance of the object 120 embodying 
the feedback comment. 

At block 154, ISAPI calls are issued from each of the objects 120 to 
populate the database 23, and more specifically the feedback table 52 and the 
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feedback details table 53, with the information contained in the instances of 
the objects 120, which operation is then actually performed at block 156. The 
method 128 then ends at block 158. 

Having now described server-side operations with respect to Figures 
7A and 7B, a description is now provided of an exemplary method 200 of 
displaying a user interface to harvest feedback, comments or opinions 
pertaining to multiple items (e.g., transactions). The method 200 shall be 
described within the context of the interfaces 110, 112 and 114 illustrated in 
Figure 6 and with reference to a flowchart illustrated in Figure 9. 

As stated above with respect to Figure 7A, at block 142, a server may 
communicate a feedback interface over the communications network to a 
client program 30 (e.g., a browser) for display. Accordingly, the method 200 
commences at block 202 with the receipt of a feedback interface in the form 
of a markup language document. The feedback interface may be, depending 
on the number of transactions, the "exceeds thresholds" multiple feedback 
interface 110 or the "does not exceed threshold" multiple feedback interface 
114. The feedback interface, in one embodiment, comprises a markup 
language document (e.g., an HTML document). 

At block 204, the client program 30 then proceeds to display 
transaction identifier information for a plurality of transactions within a 
single interface. Figure 10 provides an exemplary embodiment of the 
"exceeds threshold" multiple feedback interface 110, and the transaction 
identifier information is shown to include user identifier information 230, 
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identifying the other party (e.g., the winning bidder or the seller) involved in 
the transaction, an item identifier providing an item number (or code) 
identifying the subject matter of the transaction, an item description 234 
providing an alpha-numeric description of the subject of the transaction, 
ended date information 236, indicating the date on which the transaction 
was established through the ending of the auction process. 

At block 206, a feedback input field 238 is displayed to indicate an 
association between the input field and the transaction identifier 
information. For example, referring again to the exemplary feedback 
interface 110 shown in Figure 10, a feedback input field 238 is displayed on 
the interface 110 adjacent the transaction identifier information. The 
feedback input field 238 can receive both textual and numeric input. In an 
alternative embodiment, a drop-down menu may be provided to input one 
of a selected set of comments into the feedback input field 238. 

At block 208, the interface then receives user-inputted feedback 
information (e.g., comments or opinions) via the feedback input field 238. 
This feedback may be provided by an alpha-numeric input device, such as a 
keyboard, or by voice recognition software. In an alternative embodiment of 
the invention, the input field 238 may be replaced by a voice recording 
mechanism that allows the commentator user to leave voice feedback by 
initiating a recording process. 

At block 210, the method 200 displays a type input mechanism 
adjacent the identifier information for each transaction, the type input 
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mechanism allowing a commentator user to specify type information (e.g., 
positive, negative or neutral) feedback for the relevant transaction. 
Referring again to Figure 10, an exemplary feedback type input 240 is shown 
to include three radio buttons, one of which is selectable to identify the input 
5 into the feedback input field 238 as being positive, negative or neutral. 
Accordingly, at block 212, the interface 110 receives user-inputted type 
information via the feedback type input 240. 

At block 214, the method 200 displays a "skip" input 242, in the 
exemplary form of a radio button or check box, adjacent the identification 

10 information for each transaction displayed within the interface. Figure 10 
shows an exemplary skip input 242 comprising a radio button that is user- 
selectable to indicate that the commentator user does not wish to provide 
feedback regarding the relevant transaction. In an alternative embodiment, 
a check box may be provided to allow user indication that no feedback is 

1 5 being provided . 

As is well known in the art, within HTML a check box or radio button 
is defined by TYPE, NAME and VALUE specifiers, where the TYPE specifier 
specifies either a check box or a radio button, the NAME specifier specifies a 
variable where a return value will be stored and the VALUE specifier stores 

20 what will be returned in the variable if the check box is checked, or the radio 
button is selected. Accordingly, feedback type and skip indications may be 
communicated from the interface 110 in pairs to an ISAPI function 
implemented by the objects as described above. Each information pair may 
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comprise, for example, a name and a value. 

At block 216, the interface 110 receives the user inputted skip 
information (or identification) via the skip input 242. 

At decision box 218, a determination is made as to whether the user 
selects a "submit" button to communicate the information inputted via the 
interface 110 to the server side. If not, the method 200 loops through blocks 
204 - 216. Alternatively, if the user does select the "submit" button at 
decision box 218, field identifier and field content information (e.g., 
feedback, type information and skip information) is communicated in pairs 
from the client program 30 to the server side. The method 200 then ends at 
block 222. 

User Interfaces 

Further descriptions of exemplary user interfaces will now be 
described with reference to Figures 10 - 13. While the exemplary interfaces 
are described as comprising markup language documents displayed by a 
browser, it will be appreciated that the described interfaces could comprise 
user interfaces presented by any Windows® client application or stand- 
alone application, and need not necessarily comprise markup language 
documents. 

Figure 10, as described above, illustrates an exemplary "exceeds 
threshold" feedback interface 110 that provides a predetermined maximum 
number (e.g., 25) of discrete feedback windows 244, each window 244 being 
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dedicated to a specific one of a number of transactions or items. Each 
feedback window 244 includes transaction (or item) identification 
information, a feedback type input 240, a feedback skip input 242 and a 
feedback input field 238. Accordingly, a collection of feedback windows 
244, all displayed in a single interface 110, allow a commentator to provide 
feedback pertaining to multiple transactions or items in a convenient 
manner without having to advance through a series of distinct interfaces. 

The number of feedback windows 244 displayed in a single interface 
is limited (e.g., 25), and accordingly the interface 110 provides retreat and 
advance buttons 246 and 248 that allow a commentator user to retreat to a 
previous collection of feedback windows 244, or advance to a subsequent 
collection of feedback windows 244. 

The "exceeds threshold" feedback interface 110 furthermore includes a 
filter criteria input field 250, into which a commentator user may input a 
user identifier, or item number, to limit the number of transactions, or items, 
pertaining to which feedback is to be submitted. For example, where the 
number of transactions for which the commentator may leave feedback 
exceeds a predetermined threshold (e.g., 50), the filter allows a commentator 
user to reduce the number of transactions by specifying only transactions 
involving a particular user or pertaining to a specific item. In alternative 
embodiments, the filter criteria may comprise a keyword on which a search 
is done to locate any transactions for which the descriptions contain relevant 
keywords. The filter mechanism underlying the filter criteria input field 250 
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allows a commentator user conveniently to limit the number of feedbacks 
displayed within an interface, and also conveniently to identify specific 
transactions for which the commentator user wishes to leave feedback. 

To this end, Figure 11 illustrates an exemplary filtered multiple 
feedback interface 112 that may follow the "exceeds threshold" feedback 
interface 110 following filtering of the transactions presented in the interface 
110. 

Figure 12 illustrates an exemplary "does not exceed threshold' 
feedback interface 114, which is substantially similar to the filtered multiple 
feedback interface 112, but does not include the retreat and advance buttons 
246 and 248. It will also be noted that the interface 114 does not provide a 
filter criteria input field 250. 

Figure 13 illustrates an exemplary embodiment of the confirmation 
interface 116, described above with reference to Figure 6. 

In summary, it will be appreciated that the above described 
interfaces, and underlying technologies, provide a convenient vehicle for the 
inputting of feedback, comments or opinions regarding multiple items, or 
transactions, via a single user interface. 

Figure 15 shows a diagrammatic representation of a machine in the 
exemplary form of a computer system 300 within which a set of 
instructions, for causing the machine to perform any one of the 
methodologies discussed above, may be executed. In alternative 
embodiments, the machine may comprise a network router, a network 
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switch, a network bridge, Personal Digital Assistant (PDA), a cellular 
telephone, a web appliance or any machine capable of executing a sequence 
of instructions that specify actions to be taken by that machine. 

The computer system 300 includes a processor 302, a main memory 
304 and a static memory 306, which communicate with each other via a bus 
308. The computer system 300 may further include a video display unit 310 
(e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The 
computer system 300 also includes an alpha-numeric input device 312 (e.g. 
a keyboard), a cursor control device 314 (e.g. a mouse), a disk drive unit 
316, a signal generation device 320 (e.g. a speaker) and a network interface 
device 322 

The disk drive unit 316 includes a machine-readable medium 324 on 
which is stored a set of instructions (i.e., software) 326 embodying any one, 
or all, of the methodologies described above. The software 326 is also 
shown to reside, completely or at least partially, within the main memory 
304 and /or within the processor 302. The software 326 may further be 
transmitted or received via the network interface device 322. For the 
purposes of this specification, the term " machine-readable medium" shall 
be taken to include any medium that is capable of storing or encoding a 
sequence of instructions for execution by the machine and that cause the 
machine to perform any one of the methodologies of the present invention. 
The term "machine-readable medium" shall accordingly be taken to 
included, but not be limited to, solid-state memories, optical and magnetic 
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disks, and carrier wave signals. 

Thus, a method and system for harvesting feedback information, 
comments, and opinions regarding multiple items from users of a network- 
based transaction facility have been described. Although the present 
invention has been described with reference to specific exemplary 
embodiments, it will be evident that various modifications and changes may 
be made to these embodiments without departing from the broader spirit 
and scope of the invention. Accordingly, the specification and drawings are 
to be regarded in an illustrative rather than a restrictive sense. 
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